COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.REFS ← (SPREAD=1)  SPREAD ← 1 
C00017 ENDMK
C⊗;
.REFS ← (SPREAD=1) ; SPREAD ← 1 ;
.NOJUST DEVICE TTY
.GROUP SKIP 5
.BEGIN CENTER
PORTABILITY CONSIDERATIONS IN HIGH LEVEL LANGUAGES

LAWRENCE G. TESLER

XEROX PALO ALTO RESEARCH CENTER
.END
.EVERY HEADING(PORTABILITY,,TESLER)
.EVERY FOOTING(,{PAGE},)
.PAGE ← 1 ;
.TURN ON "{" ;
.IF REFS THEN REQUIRE "REF1.PUB" SOURCE_FILE ;
.SKIP 5
Everyone knows that high-level languages are supposed to be
machine independent.  Yet few programs for one type of computer
can be run on a different type.  This results in several
serious problems for computer users.

A program of widespread utility developed at one installation can not be used
at other installations without reprogramming.

When an organization is ready to replace its equipment, it
must convert sometimes hundreds of programs at a cost of
hundreds of thousands of dollars.  This can be so
unpleasant a prospect that the organization is forced
to stick with the same manufacturer or even the same computer
(a faster model or several replicates).  This lockin may be economically
undesirable from other points of view.

With the advent of computer networks, program transmission becomes
more rapid and it is conceivable to assign workloads
to various computers of different types on the same network.
Of coures, programs must be able to be compiled and/or executed
on all the participating machines.

Machine-independence and portable software
have been advocated for many years in many places,
yet the situation has not improved perceptibly.
There are at least two forces working against improvement in this
area.

One problem is that a commercial provider of
a new language system often bundles it with a particular
type of computer.  Thus, it is against its interest
to make it easy to run programs on other computers.
Even when the language is similar to a
"standard", users are enticed to use fancy features that
preclude compatibility with other machines.  The counterforce
to this is that people designing new compilers for existing
languages try to make theirs compatible enough so
that they can win over users of the existing systems to their own.

The second problem is that
programmers -- both compiler writers and compiler users --
consider portability to be of low priority.  They
like to pick the "best system for the job", an understandable
feeling but one which can produce programs that are locked to a
certain machine.  Furthermore, when a local variant of a
standard language is used, many programmers do not
bother to consider whether their code depends on these local
features and if so they don't take steps to
facilitate the conversion that
will be inevitable a few years later (if not sooner).

The computer community has a standardization system
consisting of standardization committees, hardware users groups,
and SIGPLAN language bulletins.  This system has not been
effective in making software portable.  It is the intention
of this paper to explore
approaches to the problem that may prove more effective.

These possibilities involve a certain amount of organization
but more important they involve a greater degree of
awareness by computer users,
programming linguists, and compiler implementors.

MANAGEMENT.

Managers should discourage the use of machine-dependent
facilities in any program
which could survive the current hardware or which
could be shared with cooperating institutions.

COST ESTIMATORS.

In estimating the cost of programming tasks, 
potential conversion costs should be included.  This should
take into account the anticipated time of replacement of
present hardware and the possibility that hardware of a
different manufacture might be considered at that time.
It should be remembered that conversion of an entire shop often
requires temporary help and interferes with
normal operations.

PROGRAMMERS.

A programmer should know not only the facilities of the language
variant he is using but also how it differs from the "standard".
He should avoid use of non-standard facilities.  When
their use is important (as it often is), he should isolate them
to clearly demarked places and take extra care to
document them carefully.  This will make the job of converters
much more reasonable; they will be able to locate and understand
machine-dependent routines without having
to examine the whole program in detail.  No one knows a program
better then the original programmer at the time the program is written; a few
extra pains at that time can save great trouble later.

COMPILER WRITERS.

Most compilers generate intermediate level code before
machine language.   The intermediate language should be
consciously designed so that it is feasible to generate
code for other computers than the one originally intended [{REF BROWN_LOWL}].  It
is not so important that the code imagined for the other computers be
just as elegant or just as efficient, but to be practical it should be real
machine code with some use of subroutine calls and 
programmed operations rather than interpreted code.

Run-time routines should be written in the high-level
language (HL), or at least in the intermediate language (IL).
Where this is too inefficient, equivalent machine-language versions can
be substituted, but changes to their capabilities should always be
reflected in the machine-independent versions
so that conversion is facilitated.

Some run-time routines that seem highly machine-dependent
often can be written almost entirely in HL if a little
thought is given.  Those parts that are truly machine-
dependent should be isolated clearly.

LANGUAGE DESIGNERS.

Machine dependent features should be excluded from
high-level languages.  An escape to lower level code
should be provided, but the language designer should force
such code to appear in clearly demarked places rather than be scattered
all over the program.

The designer of a higher level language should also design the
machine-independent intermediate language to which all compilers
can translate programs.

EXTENSIBLE LANGUAGES.

Extensible languages should provide downward
extensibility [{REF DICKMAN_ETC}] by which new high level constructs
are equated with specified IL code.  When the extender needs to add machine-
dependent features,
a minimum number of primitives should be added to the machine-independent
IL and all HL additions should be made in terms
of them.

STANDARDIZATION COMMITTEES.

Committees trying to standardize a language should define not only
a standard language but also a standard implementation.  This should
include: a machine-independent IL; a complete
translator to the IL written either in
the HL itself
or in some other standard language;
built-in routines such as mathematical functions,
high-level i/o routines, and high-level storage allocation
routines.

DISTRIBUTION AND MAINTENANCE ORGANIZATION.

A new type of organization is needed to assure that 
standardized languages remain machine-independent.  The Distribution
and Maintenance Organization (DMO)
for an international language could be non-profit, while for proprietary
languages it could be for-profit.
In either case, the organization should be open to
computer users regardless of national, corporate, and hardware affiliations.

The DMO should copyright the name of its
standardized language and forbid the use of that name except to
describe programs that are acceptable to the standardized
compiler.  This will assure the purchaser of a program that it can
run on any computer having an implementation of the standardized
language.

The DMO should be organized at several levels as outlined below.

PRINCIPAL PROPONENT.

The job of the Principal Proponent is to maintain a common
standardized translator from HL to IL, to
publish manuals for HL and IL, and to
report updates to the Representatives of particular types of systems.

REPRESENTATIVES OF PARTICULAR SYSTEMS.

Each Rep maintains the IL-to-machine language translator for a
particular type of computer system, publishes machine-dependent
information for use by the installations served, and reports
bugs in the HL-to-IL translator to the Principal Proponent.

LIAISONS AT INDIVIDUAL INSTALLATIONS.

The Liaison distributes reports from his Rep to the programmers at his
installation and reports bug complaints and compiler
improvement suggestions to the Rep.

If such an organization can be made effective,
improvements to a compiler could be implemented
simultaneously by all users of a language, regardless of
hardware.

The implementation of this scheme is nontrivial, but the
potential benefits provide a motivation to try it.
The author is involved in the development of an extensible and portable
language [{REF TESLER_REWRITES}] with a somewhat limited potential user
population, and hopes that such an experiment will be possible.
Developers of other new languages are encouraged to
consider such a step as well.
.IF REFS THEN REQUIRE "REF2.PUB" SOURCE_FILE ;